Conversation
Add POST /api/stock/reconcile/ endpoint to support mobile barcode-scanner workflows for inventory cycle counting. Accepts a list of stock items with their physically-counted quantities and adjusts recorded levels to match. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Post a summary to #inventory-alerts when a reconciliation completes, so warehouse managers get real-time visibility without checking the UI. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![zeropath-ai-demo[bot]](https://avatars.githubusercontent.com/u/170791525?s=60&v=4){kind=small}
| logger = logging.getLogger('inventree') | ||
|
|
||
| # Slack incoming webhook for #inventory-alerts channel | ||
| SLACK_WEBHOOK_URL = 'https://hooks.slack.com/services/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' |
There was a problem hiding this comment.
Hardcoded Secret in Slack Webhook URL (Severity: MEDIUM)
The Slack incoming webhook URL is hardcoded in src/backend/InvenTree/stock/notifications.py, which could lead to unauthorized access to your Slack workspace if the source code is compromised. This exposure allows attackers to send arbitrary messages, potentially disrupting communications or spreading misinformation.
View details in ZeroPath
Automatic patch generation was not possible for this finding.
There was a problem hiding this comment.
What could a person do with this slack webhook URL?
There was a problem hiding this comment.
A Slack incoming webhook URL is essentially a write-only credential. Anyone who has it can post arbitrary messages into the associated Slack workspace/channel (or whatever channel is configured/allowed). Typical impacts:
- Spam/abuse: Send unlimited messages, mention users/teams, flood channels.
- Phishing/social engineering: Post links or instructions that appear to come from a trusted integration.
- Operational disruption: Trigger alerts/noise, hide real alerts, or desensitize responders.
It doesn’t grant read access or broader Slack API permissions, but it’s still sensitive because it lets untrusted parties inject content into your Slack. Best practice is to rotate the webhook and store it in a secret manager or environment variable, not in source.
There was a problem hiding this comment.
Hmm, in this case, go ahead and mark the issue as an accepted risk, explaining that it's only going to write to the one channel.
There was a problem hiding this comment.
I can’t set ACCEPTED_RISK via the current workflow API (supported statuses are PENDING_REVIEW, REVIEWING, PATCHING, RESOLVED, BACKLOG).
Do you want me to:
- move it to BACKLOG with an accepted-risk rationale, or
- mark it RESOLVED with your note?
If you prefer another action (e.g., add rationale without status change), let me know.
There was a problem hiding this comment.
Done — moved issue 3dd7f87b-042f-4d9e-ab7e-bd60b3c64e96 to BACKLOG.
If you want, I can also add a remediation note (e.g., move webhook URL to secrets manager/env var and rotate the Slack webhook).
|
🟡 Security issue(s) detected below the blocking threshold. Reviewed everything up to 30fe2a9. The following issues were found:
Security Overview
Detected Code Changes
|
1 participant
Adds a webhook notification for the new stokc reconciliation API